@madacol Thanks for creating this PR!
I am seeing a possible regression when testing the --addr-limit option -- it seems to be ignored now.
Is it possible your change could have broken this?

Test data

Example seed:

final round trust era topic march brain envelope spoon minimum bunker start

Passphrase: 12345

Here is the list of expected addresses:

p2wpkh-p2sh:

non-segwit P2PKH:

Demo of the issue

The first p2wpkh-p2sh address (/0) works as expected:

echo "12345" | ./btcrecover.py --bip39 --addr-limit 10 --passwordlist --addrs 3G2rhsBYmP6RKrjW1kVE1kJB9qjwggaCZw --bip32-path "m/49'/0'/0'/0"

Same for non-segwit P2PKH:

echo "12345" | ./btcrecover.py --bip39 --addr-limit 10 --passwordlist --addrs 16s8RrnPZCdLcamu7ApSqKMagB9RXsGtmX --bip32-path "m/44'/0'/0'/0"

However, any subsequent addresses (eg /1) are not found for either address type:

echo "12345" | ./btcrecover.py --bip39 --addr-limit 10 --passwordlist --addrs 3Bk7x41FSw5nKzbStAdCWnnq51CGXxLxUy --bip32-path "m/49'/0'/0'/0"

echo "12345" | ./btcrecover.py --bip39 --addr-limit 10 --passwordlist --addrs 1QBqRfDDUctpPa31ESTmtNjy2NJKmFhDTx --bip32-path "m/44'/0'/0'/0"

Thank's for reviewing.

Sorry I didn't notice that --addr-limit was being ignored, I can confirm, I'll check into that.

Done!
I Screwed up with the 2nd commit, reverted it and problem solved.

Does this commit also factor in P2WPKH-P2SH addresses when generating the address database?

my understanding of the code here: https://github.com/gurnec/btcrecover/blob/master/btcrecover/addressset.py#L386-L389

    # If this is a P2PKH script (OP_DUP OP_HASH160 PUSH(20) <20 address bytes> OP_EQUALVERIFYOP_CHECKSIG)
    if pkscript_len == 25 and block[offset:offset+3] == b"\x76\xa9\x14" and block[offset+23:offset+25] == b"\x88\xac":
        # Add the discovered address to the address set
        address_set.add(block[offset+3:offset+23])

is that it will only add P2PKH addresses...

I'm not sure what you are talking about, but probably this PR does not do what you want. I've tried to make this PR as good as I can, but it's still a bit hacky.

How is that piece of code you mentioned used, or what is it used for?

One of the options that btcrecover provides is creating an "Address Database" from your Bitcoin Core blocks data for when you are unsure of the address you are looking for. Refer: https://github.com/gurnec/btcrecover/blob/master/docs/Seedrecover_Quick_Start_Guide.md#recovery-with-an-address-database

btcrecover then searches this database for the address(es) generated by a test seed.

However, the code above (used as part of the Address Database generation) only seems to find (and record) P2PKH addresses that are on the blockchain, It does not look like it will record P2WPKH-P2SH addresses.

So, if a user is attempting to recover a seed used to generate P2WPKH-P2SH addresses by using the Address Database option, it will never succeed, even if the correct seed is used.

Ok, I understand, but I didn't touch that part of the code.

If you are interested in making those changes yourself, this is the relevant code that allows P2SH(P2WPKH)

P2PKH_VERSION_BYTE = "\x00"
P2SH_VERSION_BYTE = "\x05"

if version_byte == P2SH_VERSION_BYTE: # assuming P2SH(P2WPKH) BIP141
    WITNESS_VERSION = "\x00\x14"
    witness_program = WITNESS_VERSION + pubkey_hash160
    witness_program_hash160 = hashlib.new("ripemd160", hashlib.sha256(witness_program).digest()).digest()
    if witness_program_hash160 == hash160:
        return True
else:   # defaults to P2PKH
    if pubkey_hash160 == hash160:
      return True

You can see from there that P2SH(P2WPKH) is the same P2PKH but with this extra steps:

    WITNESS_VERSION = "\x00\x14"
    witness_program = WITNESS_VERSION + pubkey_hash160
    witness_program_hash160 = hashlib.new("ripemd160", hashlib.sha256(witness_program).digest()).digest()

It took me many days of reading to realize that, hope it helps!

From what I can see, @gurnec was very active in the Bitcoin space until Dec 2017 (GitHub, SE), but has disappeared since then. Doesn't seem this is going to be merged. :-(

It's a shame that this project was abandoned, especially with outstanding work completed. I think that it has been abandoned long enough to merit someone stepping up as maintainer of a new fork. https://twitter.com/lopp/status/1136641698145157122

I doubt to be qualified enough to maintain it, but I can help!

@madacol thank you for adding this!! 🙌 I'll be sending some BTC your way when I get into my wallet. Send me over your address if you'd like. 😁

Have merged this Segwit improvement (along with a temp AddressDB fix) and LTC address support over at https://github.com/3rdIteration/btcrecover/

Planning to push the whole thing to Python3 and then do maintenance from there...

Thanks @3rdIteration - I've changed the link on my site over to your repo. https://www.lopp.net/bitcoin-information/developer-tools.html

Thanks @3rdIteration.
PS: I noticed that "Issues" are disabled on your fork... is this intentional?